Link libc++/libc++abi on macOS for static LLVM builds - #17
Conversation
Official LLVM release tarballs ship only static component libraries (no libLLVM.dylib), so llvm-sys's `prefer-dynamic` feature falls back to static linking. The LLVM archives are C++ and pull in runtime symbols (operator new, __cxa_guard_*, __cxa_pure_virtual) that the final link otherwise misses, failing with "ld: symbol(s) not found for architecture arm64". Homebrew's LLVM provides libLLVM.dylib and never hits this, which is why CI doesn't need it. Link libc++ and libc++abi in the macOS branch of openvaf-driver's build.rs so building against a static LLVM works too; the extra libs are harmless when a dynamic libLLVM is used.
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request updates the macOS build script (build.rs) to link against C++ runtime libraries, enabling compatibility when building against static LLVM release tarballs. The reviewer pointed out that explicitly linking c++abi is redundant on macOS since libc++ transitively links to it, and suggested removing that line.
Important
The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.
| println!("cargo:rustc-link-lib=dylib=c++"); | ||
| println!("cargo:rustc-link-lib=dylib=c++abi"); |
There was a problem hiding this comment.
On macOS, libc++ (linked via c++) transitively links to libc++abi [16.1.1]. Therefore, explicitly linking c++abi is redundant and unnecessary, as the dynamic linker (dyld) will automatically load it and resolve all C++ runtime symbols (such as __cxa_guard_acquire and __cxa_pure_virtual). We can safely remove the explicit link to c++abi.
| println!("cargo:rustc-link-lib=dylib=c++"); | |
| println!("cargo:rustc-link-lib=dylib=c++abi"); | |
| println!("cargo:rustc-link-lib=dylib=c++"); |
1 participant
Problem
Building
openvaf-ron macOS against an official prebuilt LLVM (e.g. theLLVM-*-macOS-ARM64.tar.xzrelease tarballs) fails at the final link with:Root cause
Those tarballs ship only static component libraries — there is no
libLLVM.dylib.mir_llvmrequestsllvm-syswith theprefer-dynamicfeature, so with no dylib present it falls back to linking the static archives. Those archives are C++ and need libc++/libc++abi for their runtime symbols, which the final link doesn't pull in.Homebrew's LLVM ships
libLLVM.dylib, so the macOS CI path never hits this.Fix
Link
c++andc++abiin the existing#[cfg(target_os = "macos")]block ofopenvaf-driver/build.rs. This only affects the final binary link (no full rebuild), and is harmless when a dynamiclibLLVMis used since those libs come in transitively anyway.Alternatives considered
Happy to switch to whichever you prefer:
llvm-config --shared-mode == static, orTesting
LLVM 21.1.6 official arm64 release (
LLVM-21.1.6-macOS-ARM64.tar.xz), Apple Silicon. With this changeopenvaf-rbuilds cleanly and compilesintegration_tests/CCCS/cccs.vato a valid arm64.osdiexporting the expectedOSDI_*symbols.